In This Topic

Exceptions returned from OPC UA operations of OPC Data Client can be

Errors generated by the target OPC UA server. It can be a standard error (service result or status code) code defined in the OPC specifications, or a custom error defined by the server vendor.
Errors from the communication infrastructure, either on the host where the OPC UA server runs, or on the client host, or the components in between.
Errors detected on the client side and generated by OPC Data Client.

A comprehensive list of possible errors cannot be given. Your program must always be ready to handle any error that it does not explicitly know about. In most cases, you will be treating all errors the same way. In some cases, you may need to have a special handling for one or a few specific errors.

Service Results

OPC UA services indicate the outcome of the operation using service results. In OPC Data Client, when the OPC UA server returns a service result that denotes an error, you will receive a UAServiceException. This object contains, among other information, a ServiceResult Property. You can use this property to distinguish between the specific errors. The value it contains is actually of the UAServiceResult type, and is further structured into various fields. In most cases, however, you are only interested in the so-called code bits (an integer) of the status code associated with the service result. The various code bits defined in the OPC UA specifications are available to you as predefined constants in the UACodeBits Class. For example, there is BadNodeIdUnknown Field, BadNotReadable Field, BadNotWritable Field etc. The UAServiceResult Class has an implicit conversion operator to an integer, which returns the code bits of the service result. This means that in order to test the UAServiceException for a specific error, you can simply take its ServiceResult Property, and compare it against the desired constant from the UACodeBits Class.

Some Common Errors

Note: The error texts are for illustration only. They are subject to change without notice. Your program should never rely on the error texts; use the exception type, and possibly other properties of the specific exception types, to distinguish between the errors.

The remote host cannot be reached

The errors in this case vary a lot, depending on factors such as the communication protocol used, or the actual configuration of the target host (when accessible, whether it drops or returns incoming packets that it does not process, etc.). You may receive e.g.:

A UAServiceException with service result "BadTcpInternalError" (when "opc.tcp" is used).
A UAServiceException with service result "BadCommunicationError" (when HTTPS is used).
An EndpointNotFoundException (when HTTP is used).
A SocketException, when "opc.tcp" is used and the host name is unknown (not found in DNS etc.).

Of course, the true cause of the exception may be that the intended host is actually running and accessible, but you have misspelled its name or IP address.

The addressed OPC UA Server is not installed or not running

The symptoms are in many cases similar as when the remote host cannot be reached.

The node you are trying to access does not exist

In this case, you will typically receive a UAServiceException with service result "BadNodeIdUnknown".

Of course, you will get the same exception if the intended node actually exists, but you have made a mistake in its Node ID.

Reading a node that is not readable, or writing a node that is not writeable

In this case, you will typically receive a UAServiceException with service result "BadNotReadable" or "BadNotWritable".

Bad or Uncertain Status of the Data

Except in methods that return the value alone (and not the UAAttributeData object), bad or uncertain status is considered a normal operational situation, and does not throw or return an exception. You are responsible for testing the status (either directly using the StatusCode Property, or indirectly using the HasValue Property) in your code before accessing the Value Property of the UAAttributeData Class, because in most cases when the status is bad, the Value is not defined (and is actually a null reference). Uncertain status usually has some value carried with the data, although its usability is questionable. For more information, see Always test the HasValue property before accessing DAVtq.Value or UAAttributeData.Value.

The methods that do not have data quality in their results, and therefore must return an error instead of the value when the value is not present, include: